home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pppext-requirements-01.txt < prev    next >
Text File  |  1993-10-07  |  51KB  |  1,338 lines
  1.  
  2.  
  3. Network Working Group                                     Drew D Perkins
  4. Internet Draft                                Carnegie Mellon University
  5. expires in six months                                       October 1993
  6.  
  7.  
  8.      Requirements for an Internet Standard Point-to-Point Protocol
  9.                 draft-ietf-pppext-requirements-01.txt
  10.  
  11.  
  12.  
  13. Status of this Memo
  14.  
  15.    This document is the product of the Point-to-Point Protocol Working
  16.    Group of the Internet Engineering Task Force (IETF).  Comments should
  17.    be submitted to the ietf-ppp@ucdavis.edu mailing list.
  18.  
  19.    Distribution of this memo is unlimited.
  20.  
  21.    This document is an Internet Draft.  Internet Drafts are working
  22.    documents of the Internet Engineering Task Force (IETF), its Areas,
  23.    and its Working Groups.  Note that other groups may also distribute
  24.    working documents as Internet Drafts.
  25.  
  26.    Internet Drafts are draft documents valid for a maximum of six
  27.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  28.    other documents at any time.  It is not appropriate to use Internet
  29.    Drafts as reference material or to cite them other than as a
  30.    ``working draft'' or ``work in progress.''
  31.  
  32.    Please check the 1id-abstracts.txt listing contained in the
  33.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  34.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  35.    current status of any Internet Draft.
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Perkins                  expires in six months                  [Page i]
  55. DRAFT             Point-to-Point Protocol Requirements      October 1993
  56.  
  57.  
  58. Abstract
  59.  
  60.    This document discusses the evaluation criteria for an Internet
  61.    Standard Data Link Layer protocol to be used with point-to-point
  62.    links.  Although many industry standard protocols and ad hoc
  63.    protocols already exist for the data link layer, none are both
  64.    complete and sufficiently versatile to be accepted as an Internet
  65.    Standard.  In preparation to designing such a protocol, the features
  66.    necessary to qualify a point-to-point protocol as an Internet
  67.    Standard are discussed in detail.  An analysis of the strengths and
  68.    weaknesses of several existing protocols on the basis of these
  69.    requirements demonstrates the failure of each to address key issues.
  70.  
  71.       Historical Note: This was the design requirements document dated
  72.       June 1989, which was followed for RFC-1134 through the present.
  73.       It is now published for completeness and future guidance.
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109. Perkins                  expires in six months                 [Page ii]
  110. DRAFT             Point-to-Point Protocol Requirements      October 1993
  111.  
  112.  
  113. 1.  Introduction
  114.  
  115.    The Internet has seen explosive growth in the number of hosts
  116.    supporting IP [1].  The vast majority of these hosts are connected to
  117.    Local Area Networks (LANs) of various types, Ethernet being the most
  118.    common.  Most of the other hosts are connected through Wide Area
  119.    Networks (WANs), such as X.25 style Public Data Networks (PDNs).
  120.  
  121.    In the past, relatively few of these hosts were connected with simple
  122.    point-to-point links.  Yet, point-to-point serial links are among the
  123.    oldest methods of data communications, and almost every host supports
  124.    point-to-point connections.  For example, asynchronous RS-232
  125.    interfaces are essentially ubiquitous.
  126.  
  127.    One reason for the small number of point-to-point IP links was the
  128.    lack of a single established encapsulation protocol.  There were
  129.    plenty of non-standard (and at least one de facto standard)
  130.    encapsulation protocols available, but there was not one which was
  131.    agreed upon as an Internet Standard.
  132.  
  133.    A number of protocols have been proposed to the Internet community,
  134.    but no consensus was reached as to which protocol should be adopted
  135.    as a standard.  The reason may be that these proposals often
  136.    addressed specific problems rather than providing general purpose
  137.    service.
  138.  
  139.    For example, one of the most successful protocols to-date was Rick
  140.    Adam's SLIP protocol for BSD UNIX [9].  SLIP provides only the most
  141.    rudimentary support for sending IP datagrams over asynchronous serial
  142.    lines, and ignores issues such as the use of protocols other than IP
  143.    and the use of synchronous links.
  144.  
  145.    This document proposes a set of requirements for an Internet Standard
  146.    point-to-point protocol (ISPPP).  Its purpose is not to propose any
  147.    one design for the standard; any solutions outlined in the text are
  148.    intended only as examples, and do not preclude other implementations.
  149.  
  150.    The document is divided into four major sections.  The first section
  151.    defines a number of technical terms used in this document.  The
  152.    second section lists the proposed requirements and details some
  153.    issues that are ignored by other protocols.  The third section
  154.    attempts to clarify a number of non-requirements.  The fourth section
  155.    analyzes existing protocols in light of the proposed requirements and
  156.    discusses the failure of each to address key issues.
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164. Perkins                  expires in six months                  [Page 1]
  165. DRAFT             Point-to-Point Protocol Requirements      October 1993
  166.  
  167.  
  168. 1.1.  Definitions of Terms
  169.  
  170.    This section defines many of the terms which will be used in further
  171.    sections of this document.  The terms "layer" and "level" are used
  172.    extensively and refer to protocol layers as defined by the
  173.    International Organization For Standardization's Reference Model
  174.    (ISORM) standard.  In particular, the terms Physical Layer, Data Link
  175.    Layer and Network Layer refer to layers one, two and three
  176.    respectively of the ISORM.  A "higher layer" refers to one with a
  177.    numerically larger layer number.
  178.  
  179.    datagram
  180.       The unit of transmission in the network layer (such as IP).  A
  181.       datagram may be encapsulated in one or more packets (q.v.) passed
  182.       to the data link layer.
  183.  
  184.    data link layer
  185.       Layer two in the ISO reference model.  Defines how bits
  186.       transmitted and received by the physical layer are recognized as
  187.       bytes and frames.  May also define procedures for error detection
  188.       and correction, sequencing and flow control.
  189.  
  190.    fragment
  191.       The result of fragmentation.  Fragmentation at the network layer
  192.       breaks large datagrams into multiple parts less than or equal to
  193.       the size of the packets passed to the data link layer.
  194.       Fragmentation at the data link layer breaks large packets into
  195.       multiple frames.
  196.  
  197.    frame
  198.       The unit of transmission at the data link layer.  A frame may
  199.       include a header and/or a trailer along with some number of units
  200.       of data.
  201.  
  202.    framing protocol
  203.       A protocol at the data link level for marking the beginning and
  204.       end of a frame transmitted across a link.
  205.  
  206.    internet
  207.       An interconnected system of networks tied together by a common
  208.       "internet protocol" providing a common and consistent network
  209.       address structure.
  210.  
  211.    Internet
  212.       Specifically refers to the IP Internet.
  213.  
  214.    Internet Standard Point-to-Point Protocol (ISPPP)
  215.       A point-to-point protocol which is declared an official Internet
  216.  
  217.  
  218.  
  219. Perkins                  expires in six months                  [Page 2]
  220. DRAFT             Point-to-Point Protocol Requirements      October 1993
  221.  
  222.  
  223.       Standard.  This protocol does not yet exist, but its proposed
  224.       characteristics are presented in this paper.
  225.  
  226.    Maximum Transmission Unit (MTU)
  227.       The maximum allowable length for a packet (q.v.) transmitted over
  228.       a point-to-point link without incurring network layer
  229.       fragmentation.
  230.  
  231.    network layer
  232.       Layer three in the ISO reference model.  Responsible for routing
  233.       packets (q.v) between physical networks.
  234.  
  235.    octet
  236.       A unit of transmission consisting of 8 bits.  On most machines an
  237.       octet is the same as a byte or a character, but this need not be
  238.       true.
  239.  
  240.    packet
  241.       The unit of transmission passed across the interface between the
  242.       network layer and the data link layer.  A packet is usually mapped
  243.       to a frame (q.v); the exception is when data link layer
  244.       fragmentation is being performed.
  245.  
  246.    physical layer
  247.       The first layer in the ISO reference model.  Describes electrical,
  248.       mechanical and timing characteristics of a link.
  249.  
  250.    point-to-point protocol (ppp)
  251.       A data link layer protocol for the transmission of packets (q.v.)
  252.       over a point-to-point link.  In the following discussion, the
  253.       acronym "ppp" refers to any generic point-to-point protocol.
  254.  
  255.    serial line IP (slip)
  256.       Often incorrectly used as a synonym for "point-to-point protocol",
  257.       "slip" specifically refers to any protocol for the transmission of
  258.       IP datagrams over a serial point-to-point line.
  259.  
  260.    SLIP
  261.       Although many proposed protocols are named "SLIP", this document
  262.       will use SLIP (uppercase) to refer to Rick Adam's slip (q.v.) for
  263.       BSD UNIX [9].
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274. Perkins                  expires in six months                  [Page 3]
  275. DRAFT             Point-to-Point Protocol Requirements      October 1993
  276.  
  277.  
  278. 2.  Required Features
  279.  
  280.    In order for a point-to-point protocol to be accepted by the Internet
  281.    community it must adequately address many requirements.  This section
  282.    itemizes and discusses the proposed requirements.  Although the main
  283.    emphasis of the discussion is on protocol architecture requirements,
  284.    implementation requirements are sometimes discussed as well.
  285.  
  286.    These particular requirements were chosen to assure that the ISPPP
  287.    adequately serves the needs of its users.  Some of these needs are
  288.    universal and dictate clear requirements for the protocol; for
  289.    example, a packet framing protocol is a fundamental necessity.  Other
  290.    needs are more specific and may even be conflicting.  Connection
  291.    liveness determination is very important on some links but can be
  292.    very expensive on others.  A standard protocol must address all of
  293.    these needs; in particular, it must be able to resolve conflicts
  294.    effectively.
  295.  
  296.    Resolving these conflicts requires that a protocol feature have both
  297.    enabled and disabled modes and that these modes must be compatible
  298.    with each other.  The enabled mode allows the protocol to solve
  299.    problems in environments where they exist.  The disabled mode allows
  300.    problems to be ignored in environments where they do not exist.  To
  301.    assure interoperabilty, implementations are required to support both
  302.    modes and allow the user (not necessarily human) to dynamically
  303.    choose which is appropriate.
  304.  
  305.    This is essentially the same solution used in the User Datagram
  306.    Protocol (UDP) [2].  The UDP datagram checksum may be computed
  307.    (enabled mode) or it may not (disabled mode).  Compatibility is
  308.    maintained by requiring the checksum to be transmitted as zero in
  309.    disabled mode and ignored when received as zero in either mode.
  310.    Implementations of UDP are generally encouraged to support both modes
  311.    but allow the application to choose modes.
  312.  
  313.  
  314. 2.1.  Simplicity
  315.  
  316.    The ISPPP must be simple.  The Internet architecture very carefully
  317.    places the most complexity in the transport layer (that is, TCP).
  318.    The internetwork layer (IP) is a fairly simple, almost stateless
  319.    protocol providing an unreliable datagram service.  The data link
  320.    layer need provide no more capability than the IP protocol; no error
  321.    correction, sequencing or flow control is necessary.  Including these
  322.    would in most cases needlessly duplicate the capabilities of the
  323.    transport layer, and might possibly decrease efficiency.  This is not
  324.    to say that these capabilities must never be included; there are some
  325.    cases which may warrant them.  For instance, very noisy links may be
  326.  
  327.  
  328.  
  329. Perkins                  expires in six months                  [Page 4]
  330. DRAFT             Point-to-Point Protocol Requirements      October 1993
  331.  
  332.  
  333.    more efficiently handled using a more complex data link layer
  334.    protocol such as CCITT's LAPB.  Nevertheless, the watchword for a
  335.    point-to-point protocol should be simplicity.
  336.  
  337.    A simple design also decreases the incidence of programming errors,
  338.    thereby increasing the likelihood of interoperability among different
  339.    implementations.  Since interoperability is a primary goal of
  340.    standardization, this is another strong argument for simplicity.
  341.  
  342.  
  343. 2.2.  Transparency
  344.  
  345.    The ISPPP must be transparent to higher layers.  The protocol must
  346.    not place any constraints on transmitted data.  All ISPPP data,
  347.    including higher level headers as well as data, must be transported
  348.    unmodified end-to-end.  No restrictions are placed on how the ISPPP
  349.    accomplishes this.  For example, if the ISPPP uses a particular
  350.    character for framing, it must also provide some way of
  351.    disambiguating higher level data containing that character from a
  352.    framing character (such as escaping or bit-stuffing).  This is mainly
  353.    an issue for the data link and physical layer protocols incorporated
  354.    into the ISPPP.
  355.  
  356.  
  357. 2.3.  Packet Framing
  358.  
  359.    The ISPPP must be able to correctly and efficiently frame packets.  A
  360.    receiver must be able to locate correctly the beginning and end of
  361.    each transmitted packet.  Within each packet, the receiver must be
  362.    able to identify the boundaries of each octet.  Finally, within each
  363.    octet, each bit must be located and identified.  No restrictions
  364.    other than those specified in this document are placed on the packet
  365.    framing protocol.
  366.  
  367.  
  368. 2.4.  Bandwidth Efficiency
  369.  
  370.    The ISPPP must make efficient use of available bandwidth.  At most,
  371.    the ppp overhead may impose a few percent reduction in raw link
  372.    bandwidth.
  373.  
  374.  
  375. 2.5.  Protocol Processing Efficiency
  376.  
  377.    The processing of the ISPPP headers must typically be very fast and
  378.    efficient.  The format for data packets should be very simple in the
  379.    normal case, without complex field checking.
  380.  
  381.  
  382.  
  383.  
  384. Perkins                  expires in six months                  [Page 5]
  385. DRAFT             Point-to-Point Protocol Requirements      October 1993
  386.  
  387.  
  388. 2.6.  Protocol Multiplexing
  389.  
  390.    The ISPPP must support multiplexing of many higher level protocols.
  391.    Although the Internet community is interested mainly in IP, co-
  392.    existence of other protocols is frequently required.  IP networks
  393.    must often support additional protocols such as AppleTalk, DECnet,
  394.    IPX, and XNS.  For point-to-point links to connect gateways on
  395.    geographically separated Local Area Networks (LANs), the ISPPP must
  396.    simultaneously support all protocols implemented on both the LANs and
  397.    the gateways.  This suggests that the ISPPP must include a protocol
  398.    type field or other multiplexing scheme.  Given the large number of
  399.    protocols, the potential use of the protocol type field as a data
  400.    compression aid, and the experimental nature of the Internet, eight
  401.    bits of type field are not sufficient.  Sixteen bits of type field
  402.    are suggested, although twelve bits (4096 protocols) should suffice.
  403.  
  404.  
  405. 2.7.  Multiple Physical and Data Link Layer Protocols
  406.  
  407.    The ISPPP must support a multiplicity of physical and data link layer
  408.    protocols.  Many types of point-to-point links exist.  Links can be
  409.    serial or parallel, synchronous or asynchronous, low speed or high
  410.    speed, electrical or optical.  Standards are required for the
  411.    transmission of IP datagrams over each type of commonly used link.
  412.  
  413.    The ISPPP must not inhibit the use of any type of link.  This
  414.    includes, but is not limited to, asynchronous, bit-oriented
  415.    synchronous (HDLC [10] and X.25 LAPB [11]), and byte-oriented
  416.    synchronous (BISYNC and DDCMP [15]) links.
  417.  
  418.    The ISPPP must initially provide support for at least the following
  419.    types of links:
  420.  
  421.       Full duplex asynchronous RS-232 [3] links with 8 bits of data and
  422.       no parity, ranging in speeds from 300 to 19.2k bps or more.
  423.  
  424.       Full duplex bit-oriented synchronous links including RS-422, RS-
  425.       423, V.35 and T1.
  426.  
  427.    Other links should be standardized as the need arises.
  428.  
  429.  
  430. 2.8.  Error Detection
  431.  
  432.    The ISPPP must provide some form of basic error detection.  Most
  433.    network and transport layer protocols provide mechanisms to detect
  434.    corrupted packets.  However, some network protocols expect error free
  435.    transmission and either provide error detection only on a conditional
  436.  
  437.  
  438.  
  439. Perkins                  expires in six months                  [Page 6]
  440. DRAFT             Point-to-Point Protocol Requirements      October 1993
  441.  
  442.  
  443.    basis or do not provide it at all.  It is the consensus of the
  444.    Internet community that error correction should always be implemented
  445.    in the end-to-end transport, but that link error detection in the
  446.    form of a checksum, Cyclic Redundancy Check (CRC) or other frame
  447.    check mechanism is useful to prevent wasted bandwidth from
  448.    propagation of corrupted packets.  Link level error correction is not
  449.    required.
  450.  
  451.  
  452. 2.9.  Standardized Maximum Packet Length (MTU)
  453.  
  454.    The ISPPP must have a standardized default maximum packet length for
  455.    each type of point-to-point link.  This standardization helps to
  456.    promote interoperable implementations.  Higher layer protocols must
  457.    not attempt to transmit packets longer than the MTU.  If a higher
  458.    layer protocol does try to transmit a packet which is too long, the
  459.    ISPPP must drop the packet and return an error.  The MTU may
  460.    potentially be changed from the default via some sort of explicit
  461.    negotiation or private agreement, but the default must be enforced in
  462.    all other cases.  The default should be at least 1500 bytes, to
  463.    efficiently carry common LAN traffic.
  464.  
  465.  
  466. 2.10.  Switched and Non-Switched Media
  467.  
  468.    The ISPPP must be able to support both switched (dynamic) and non-
  469.    switched (static) point-to-point links.  A common example of a non-
  470.    switched link is a 3-wire asynchronous RS-232 cable which might
  471.    connect a host to a particular gateway.  Switched media may be
  472.    exemplified by connections over a standard voice network or an
  473.    Integrated Services Digital Network (ISDN).  Links over ISDN are
  474.    currently rare, but are expected to become increasingly commonplace.
  475.    To be a viable standard, the ISPPP must be able to effectively
  476.    support both types of links.  Procedures for establishing switched
  477.    connections are beyond the scope of this document.
  478.  
  479.  
  480. 2.11.  Symmetry
  481.  
  482.    The ISPPP should operate symmetrically to maximize flexibility.  The
  483.    ISPPP must allow communications among any combination of gateways and
  484.    hosts.  One host may need to communicate directly with another host,
  485.    or it may be connected to a gateway to gain access to a whole
  486.    network.  A gateway may establish a connection to a single host in
  487.    order to deliver a packet, or it may connect to another gateway on a
  488.    permanent or transient basis.  Symmetry is destroyed by pre-assigned
  489.    static roles, such as master and slave or gateway and host.  If
  490.    necessary, roles may be dynamically determined on a per connection
  491.  
  492.  
  493.  
  494. Perkins                  expires in six months                  [Page 7]
  495. DRAFT             Point-to-Point Protocol Requirements      October 1993
  496.  
  497.  
  498.    basis.
  499.  
  500.  
  501. 2.12.  Connection Liveness
  502.  
  503.    The ISPPP must include a mechanism to automatically determine when a
  504.    link is functioning properly and when it is defunct.  This mechanism
  505.    should be enabled by default, but the protocol and all
  506.    implementations must allow this mechanism to be disabled.
  507.  
  508.    When enabled, this mechanism should discover changes in a link's
  509.    status in a timely fashion -- no more than a few minutes.  Continuing
  510.    to utilize a link which is down often causes routing problems
  511.    commonly referred to as "black holes".  These problems can be hard to
  512.    find and diagnose.  By automatically detecting a failing link, a
  513.    point-to-point protocol can avoid such problems, and also provide a
  514.    powerful tool for a network manager trying to locate and remedy the
  515.    fault.
  516.  
  517.    When a point-to-point connection is not functioning properly, it must
  518.    be declared "down" for the purposes of routing packets for higher
  519.    level protocols.  In order to certify a link "up", the systems on
  520.    either end of the link must be able to successfully exchange packets.
  521.    In other words, the systems at both ends must be able both to
  522.    transmit and to receive packets, and the link must be able to
  523.    transport packets in both directions.  Links are defined to be "down"
  524.    at initialization, their liveness must be verified before they may be
  525.    declared "up".
  526.  
  527.    This feature may be disabled in situations where connection status
  528.    determination is "expensive".  For example, a link may traverse a
  529.    Public Data Network (such as TELENET or TYMNET) which accounts for
  530.    bandwidth utilization.  Constant pinging would result in charges
  531.    being accrued even in the absence of useful communications.
  532.  
  533.  
  534. 2.13.  Loopback Detection
  535.  
  536.    The ISPPP must be capable of automatically detecting a looped-back
  537.    link without operator assistance.  Modems and other communications
  538.    gear are often placed in a loopback mode to aid in diagnosis of
  539.    circuit failures.  Detection of this condition must take no longer
  540.    than one period of the liveness protocol.  While the link is in
  541.    loopback mode, each end of the link must declare the other end to be
  542.    unreachable.  However, to aid in diagnosis, each end of the link may
  543.    declare itself reachable for any higher-level protocol which
  544.    distinguishes between the two ends of the link.
  545.  
  546.  
  547.  
  548.  
  549. Perkins                  expires in six months                  [Page 8]
  550. DRAFT             Point-to-Point Protocol Requirements      October 1993
  551.  
  552.  
  553. 2.14.  Misconfiguration Detection
  554.  
  555.    The ISPPP must be able to quickly detect misconfigured point-to-point
  556.    connections.  A connection which is misconfigured must never be
  557.    declared to be up.  Many systems, gateways in particular, have more
  558.    than one point-to-point connection.  When many cables terminate
  559.    within a small area, the possibility for confusion abounds.  It
  560.    becomes very easy to mistakenly plug a cable into the wrong
  561.    connector, or even to swap cables.  The protocol should do its best
  562.    to provide protection against these errors by verifying the remote
  563.    end's identity whenever possible before marking an interface as
  564.    operational.  The purpose of this verification is not rigorous
  565.    authentication but the detection of simple errors.
  566.  
  567.  
  568. 2.15.  Network Layer Address Negotiation
  569.  
  570.    The ISPPP must allow network layer (such as IP) addresses to be
  571.    negotiated.  The negotiation algorithm should be as simple as
  572.    possible and must be guaranteed to terminate in all cases.  Many
  573.    network layer protocols and implementations are required to know the
  574.    addresses at both ends of a point-to-point link before packets may be
  575.    routed.  These addresses may be statically configured, but it may
  576.    sometimes be necessary or convenient for these addresses be
  577.    dynamically ascertained at connection establishment.  This is
  578.    especially important when switched media are used.  For example, a
  579.    dial-up IP gateway must know the IP address of its peer before
  580.    packets can be successfully routed.  This address can be either
  581.    statically or dynamically configured.  In the former case, the
  582.    gateway's peer must therefore learn the static address (static with
  583.    respect to the gateway).  In the latter situation, the gateway must
  584.    dynamically learn the address used by its peer.
  585.  
  586.  
  587. 2.16.  Data Compression Negotiation
  588.  
  589.    The ISPPP must provide a way to negotiate the use of data compression
  590.    algorithms.  This mechanism should be as simple as possible and must
  591.    be guaranteed to terminate in all cases.  The protocol is not
  592.    required to standardize any data compression algorithms; conforming
  593.    implementations of the protocol therefore may refuse to do data
  594.    compression when negotiating (refusal to do data compression always
  595.    takes precedence over an offer to do it).  However, to allow the use
  596.    of data compression between consenting systems, the point-to-point
  597.    protocol must not impede the use of data compression.  In fact, it
  598.    should be possible to use multiple, independent data compression
  599.    schemes simultaneously.
  600.  
  601.  
  602.  
  603.  
  604. Perkins                  expires in six months                  [Page 9]
  605. DRAFT             Point-to-Point Protocol Requirements      October 1993
  606.  
  607.  
  608.    Because data compression algorithms are still very experimental in
  609.    the Internet environment, it is likely that many different algorithms
  610.    will be tried.  The negotiation protocol must distinguish between
  611.    these different algorithms to ensure that data compression is not
  612.    enabled unless the same algorithm or algorithms are used at both ends
  613.    of the connection.  The number of such supported algorithms must be
  614.    easily extensible.
  615.  
  616.  
  617. 2.17.  Extensibility and Option Negotiation
  618.  
  619.    The ISPPP must allow for future extensions in a flexible way.  The
  620.    Internet will never cease to evolve.  Changes in technology and user
  621.    demands create new requirements.  To function effectively as a
  622.    standard, the protocol must have the ability to evolve along with its
  623.    environment.
  624.  
  625.    To accomplish this, the ISPPP should be designed to be as extensible
  626.    as possible and to allow for experimentation within the guidelines of
  627.    the other requirements presented in this document.  A proposed
  628.    solution is to specify an option negotiation protocol.  The option
  629.    negotiation protocol could be used for the negotiation of network
  630.    layer addresses, data compression schemes, MTU, encryption, etc.  The
  631.    option negotiation protocol must itself be extensible; it should
  632.    allow the negotiation of a large number of future options and it
  633.    should allow the use of other types of point-to-point links and
  634.    encapsulation schemes.
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659. Perkins                  expires in six months                 [Page 10]
  660. DRAFT             Point-to-Point Protocol Requirements      October 1993
  661.  
  662.  
  663. 3.  Features Not Required
  664.  
  665.    This section discusses functionality which is explicitly not
  666.    required.  These functions may potentially be included in
  667.    implementations as long as the inclusion does not violate any of the
  668.    requirements itemized in the previous section.
  669.  
  670.  
  671. 3.1.  Error Correction
  672.  
  673.    As discussed above in the sections on Simplicity and Error Detection,
  674.    error correction is the responsibility of the transport layer and is
  675.    not required in a point-to-point protocol.  However, on links with
  676.    high error rates, performance may be increased by adding error
  677.    correction at the data link level.  Therefore, the ISPPP must not
  678.    prevent the addition of error correction by private agreement, even
  679.    though such mechanisms are not required in the basic implementation.
  680.  
  681.  
  682. 3.2.  Flow Control
  683.  
  684.    Flow control (such as XON/XOFF) is not required.  Any implementation
  685.    of the ISPPP is expected to be capable of receiving packets at the
  686.    full rate possible for the particular data link and physical layers
  687.    used in the implementation.  If higher layers cannot receive packets
  688.    at the full rate possible, it is up to those layers to discard
  689.    packets or invoke flow control procedures.  As discussed above, end-
  690.    to-end flow control is the responsibility of the transport layer.
  691.    Including flow control within a point-to-point protocol often causes
  692.    violation of the simplicity requirement.
  693.  
  694.  
  695. 3.3.  Sequencing
  696.  
  697.    Sequencing of packets is not required.  The ISPPP need provide no
  698.    more service than the IP protocol, an unreliable datagram service
  699.    which is free to reorder packets.  In fact, it is specifically
  700.    allowed to reorder packets based upon some type-of-service criteria
  701.    implemented in higher-level protocols.
  702.  
  703.  
  704. 3.4.  Backward Compatibility
  705.  
  706.    There is no requirement for the ISPPP to provide backward
  707.    compatibility with any other point-to-point protocol.  First, there
  708.    are no official Internet Standards with which backward compatibility
  709.    must be maintained.  Second, attempting to maintain backward
  710.    compatibility may lead to needless restrictions on the new protocol.
  711.  
  712.  
  713.  
  714. Perkins                  expires in six months                 [Page 11]
  715. DRAFT             Point-to-Point Protocol Requirements      October 1993
  716.  
  717.  
  718.    However, there is no need for the designers of the ISPPP to go out of
  719.    their way to inhibit backward compatibility.
  720.  
  721.  
  722. 3.5.  Multi-Point Links
  723.  
  724.    There is no requirement for supporting multi-point links.  Many
  725.    features which are required are only valid between two peers.  These
  726.    links are sufficiently rare that the benefits of supporting them are
  727.    outweighed by the added complexity their support would introduce into
  728.    the ISPPP.
  729.  
  730.       Historical Note: The original rationale also stated: "Furthermore,
  731.       it is unlikely that many new types of multi-point links will be
  732.       introduced in the foreseeable future."  Since this was written,
  733.       considerable effort has been expended in new multi-point links,
  734.       including Switched Multimegabit Data Service, Frame Relay, and
  735.       Asynchronous Transfer Mode.  However, it is clear that these are
  736.       considerably more complex than ISPPP.
  737.  
  738.  
  739. 3.6.  Half-Duplex or Simplex Links
  740.  
  741.    Support for half-duplex or simplex links is not required.  These
  742.    types of links are not in common use in the current Internet.  Half-
  743.    duplex links require some method of turning the line around.  The
  744.    ISPPP need not have an explicit mechanism for handling line turn-
  745.    around.  Such support might possibly be added in the future via the
  746.    required extension mechanism.
  747.  
  748.  
  749. 3.7.  7-bit Asynchronous RS-232 Links
  750.  
  751.    The use of asynchronous RS-232 need not support 7-bit links.  8-bit
  752.    links are predominant in the Internet environment and supporting 7-
  753.    bit links introduces unnecessary complexity.
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769. Perkins                  expires in six months                 [Page 12]
  770. DRAFT             Point-to-Point Protocol Requirements      October 1993
  771.  
  772.  
  773. 4.  Prior Work On PPP Protocols
  774.  
  775. This section reviews a number of existing point-to-point and data link
  776. layer protocols and points out which of our requirements are not
  777. satisfied.
  778.  
  779. 4.1.  Internet Protocols
  780.  
  781. 4.1.1.  RFC 891 - DCN Local-Network Protocols, Appendix A
  782.  
  783.    In Appendix A of RFC 891, "DCN Local-Network Protocols" [4], D.L.
  784.    Mills describes the data link layer packet formats used by the
  785.    Fuzzball system for asynchronous, character-oriented synchronous,
  786.    DDCMP, HDLC, ARPANET 1822, X.25 LAPB and ethernet links.  These
  787.    protocols meet the stated requirements for simplicity, transparency,
  788.    packet framing and efficiency, but fall short of many of the others.
  789.    Most of these protocols assume the use of the IP protocol, and do not
  790.    include any type of protocol demultiplexing field.  No error
  791.    detection mechanism is provided except when necessary to comply with
  792.    another standard such as ethernet.  RFC 891 does not mention the MTU
  793.    used for any of these links.  Other requirements such as loopback
  794.    detection and misconfiguration detection are not discussed.  Finally,
  795.    no option negotiation scheme is defined; without a protocol
  796.    demultiplexing field it would be difficult or impossible to include
  797.    one.
  798.  
  799.  
  800. 4.1.2.  RFC 914 - Thinwire Protocols
  801.  
  802.    RFC 914, "Thinwire Protocols" [5], discusses the use of low speed
  803.    links in the Internet.  This document places its main emphasis on
  804.    decreasing round-trip delay and increasing link efficiency with the
  805.    help of header compression (vs. data compression) techniques.  Three
  806.    "Thinwire" protocols are discussed, Thinwire I, Thinwire II and
  807.    Thinwire III.  The latter two protocols require the use of a reliable
  808.    data link layer protocol; one such protocol, "SLIP" (not to be
  809.    confused with Rick Adams' SLIP), is proposed in Appendix D of the
  810.    RFC.  As proposed, "SLIP" does not meet many of the stated
  811.    requirements.  Although not terribly complex, as a reliable, error
  812.    detecting and correcting protocol, it is not "simple".  The 32 octet
  813.    packet size makes it inefficient for large or uncompressed packets,
  814.    requiring complex fragmentation and reassembly.  The use of other
  815.    than asynchronous links is not mentioned.  The entire reliable link
  816.    layer would be redundant over LAPB links.  There is no mechanism for
  817.    option negotiation or future extensibility.
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824. Perkins                  expires in six months                 [Page 13]
  825. DRAFT             Point-to-Point Protocol Requirements      October 1993
  826.  
  827.  
  828. 4.1.3.  RFC 916 - Reliable Asynchronous Transfer Protocol
  829.  
  830.    RFC 916 [6] presents RATP, the Reliable Asynchronous Transfer
  831.    Protocol.  RATP provides error detection and correction, sequencing
  832.    and flow control across a point-to-point connection.  It is directed
  833.    towards full duplex RS-232 links although it is useful for other
  834.    point-to-point links.  Although the author claims that RATP is not as
  835.    complex as some other protocols, it is far from simple.  RATP solves
  836.    many of the problems which we have labeled non-requirements and fails
  837.    to solve many of our stated requirements.  Specifically, RATP does
  838.    not support option negotiation and has no mechanism for future
  839.    extensibility.  Since RFC 916 was published, no consensus has emerged
  840.    advocating RATP.  For these reasons RATP is not recommended as the
  841.    ISPPP.
  842.  
  843.  
  844. 4.1.4.  RFC 935 - Reliable Link Layer Protocols
  845.  
  846.    RFC 935 [7] is a rebuttal to the protocols proposed in RFCs 914 and
  847.    916.  J. Robinson discusses existing and widely-used national and
  848.    international standards which meet the needs addressed by the two
  849.    prior RFCs.  The standards reviewed include character-oriented
  850.    asynchronous and synchronous (bisynch) protocols and bit-oriented
  851.    synchronous protocols.  RFC 935 does not present any higher level
  852.    issues such as option negotiation or extensibility.
  853.  
  854.  
  855. 4.1.5.  RFC 1009 - Requirements for Internet Gateways
  856.  
  857.    Section 3 of RFC 1009, "Constituent Network Interfaces" [8], briefly
  858.    discusses requirements for transmission of IP datagrams over a number
  859.    of types of point-to-point links including X.25 LAPB, HDLC framed
  860.    synchronous links, Xerox Synchronous Point-to-Point synchronous lines
  861.    and the MIT Serial Line Framing Protocol for asynchronous lines.  RFC
  862.    1009 merely mentions these as reasonable candidates and does not go
  863.    into depth on any of them.  All are discussed further in this
  864.    document.
  865.  
  866.  
  867. 4.1.6.  RFC 1055 - Serial Line IP
  868.  
  869.    Rick Adams' Serial Line IP (SLIP) protocol [9] has become something
  870.    of a de facto standard due to the popularity of the 4.2 and 4.3BSD
  871.    UNIX operating systems.  SLIP is easily added to 4.2 systems and is
  872.    included with 4.3.  Many other TCP/IP implementation have added SLIP
  873.    implementations in order to be compatible.  Yet SLIP is not a real
  874.    standard; the protocol was only recently published in RFC form.
  875.    Before RFC 1055 it was specified in the SLIP source code.
  876.  
  877.  
  878.  
  879. Perkins                  expires in six months                 [Page 14]
  880. DRAFT             Point-to-Point Protocol Requirements      October 1993
  881.  
  882.  
  883.    SLIP does not meet most of the requirements set forth above.  SLIP
  884.    certainly meets the requirement for simplicity, and also meets the
  885.    requirements for transparency and bandwidth efficiency.  But SLIP
  886.    only provides for sending IP packets over asynchronous serial lines.
  887.    Since it provides no higher level protocol field for demultiplexing,
  888.    SLIP cannot support multiple concurrent higher level protocols.
  889.    Providing only a framing protocol, SLIP would be entirely redundant
  890.    when used with a LAPB synchronous link.  SLIP includes absolutely no
  891.    mechanism for error detection, not even parity.  Again due to its
  892.    lack of a protocol type field, SLIP does not support any type of
  893.    option negotiation or extensibility.
  894.  
  895.  
  896. 4.2.  International Protocols
  897.  
  898. 4.2.1.  ISO 3309 - HDLC Frame Structure
  899.  
  900.    ISO 3309 [10], the HDLC frame structure, is a simple data link layer
  901.    protocol which provides framing of packets transmitted over bit-
  902.    oriented synchronous links.  Special flag sequences mark the
  903.    beginning and end of frames and bit stuffing allows data containing
  904.    flag characters to be transmitted.  A 16-bit Frame Check Sequence
  905.    provides error detection.
  906.  
  907.    By itself, the HDLC frame structure does not meet most of the
  908.    requirements.  HDLC does not provide protocol multiplexing, standard
  909.    MTUs, fault detection or option negotiation.  There is no mechanism
  910.    for future extensibility.
  911.  
  912.    Given the HDLC frame structure's wide acceptance and simplicity, it
  913.    may be an ideal building block for the ISPPP.
  914.  
  915.  
  916. 4.2.2.  ISO 6256 - HDLC Balanced Class of Procedures
  917.  
  918.    ISO 6256, the HDLC Balanced Class of Procedures, specifies a data
  919.    link layer protocol which provides error correction, sequencing and
  920.    flow control.  ISO 6256 builds on ISO 3309 and ISO 4335, HDLC
  921.    Elements of Procedures.
  922.  
  923.    As far as meeting our requirements is concerned, ISO 6256 does not
  924.    provide any more utility than does ISO 3309.  The capabilities that
  925.    are provided are all considered unnecessary and overly complex.
  926.  
  927.  
  928. 4.2.3.  CCITT X.25 and X.25 LAPB
  929.  
  930.    CCITT recommendation X.25 [11] describes a network layer protocol
  931.  
  932.  
  933.  
  934. Perkins                  expires in six months                 [Page 15]
  935. DRAFT             Point-to-Point Protocol Requirements      October 1993
  936.  
  937.  
  938.    providing error-free, sequenced, flow controlled virtual circuits.
  939.    X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335
  940.    and 6256.  Neither X.25 LAPB or full LAPB meet any more of our
  941.    requirements than the ISO protocols.
  942.  
  943.  
  944. 4.2.4.  CCITT I.441 LAPD
  945.  
  946.    CCITT I.441 LAPD [12] defines the Link Access Procedure on the ISDN
  947.    D-Channel.  The data link layer of LAPD is very similar to that of
  948.    LAPB and fails to meet the same requirements.
  949.  
  950.  
  951. 4.3.  Other Protocols
  952.  
  953. 4.3.1.  Cisco Systems point-to-point protocols
  954.  
  955.    The Cisco Systems gateway supports both asynchronous links using SLIP
  956.    and synchronous links using either simple HDLC framing, X.25 LAPB or
  957.    full X.25.  The HDLC framing procedure includes a four byte header.
  958.    The first octet (address) is either 0x0F (unicast intent) or 0x8F
  959.    (multicast intent).  The second octet (control byte) is left zero and
  960.    is not checked on reception.  The third and fourth octets contain a
  961.    standard 16 bit Ethernet protocol type code.
  962.  
  963.    A "keepalive" or "beaconing" protocol is used to ensure the two-way
  964.    connectivity of the serial line.  Each end of the link periodically
  965.    sends two 32 bit sequence numbers to the other side.  One sequence
  966.    number is the local side's sequence number, the other is the sequence
  967.    number received from the other side.  Hearing the local sequence
  968.    number from the other side indicates that the link is working in both
  969.    directions.
  970.  
  971.    The keepalive protocol is extensible.  One extension is used to
  972.    default IP addresses on serial lines of systems without non-volatile
  973.    memory.  A request for address is sent to the remote side.  The
  974.    remote side responds with its own IP address and a subnet mask.  When
  975.    the querying side receives the reply, it checks if the host portion
  976.    of the remote address is either 1 or 2.  If so, the opposite address
  977.    is chosen for the local address.  If not, the protocol cannot be used
  978.    and we must rely on other address resolution means.  This protocol
  979.    assumes that each serial link uses one subnet or network number.
  980.  
  981.    LAPB assuming IP is another possible encapsulation.  A multi-protocol
  982.    extension of LAPB (multi-LAPB) includes a 16 bit Ethernet type code
  983.    after the address and control bytes and in front of the actual
  984.    protocol data.
  985.  
  986.  
  987.  
  988.  
  989. Perkins                  expires in six months                 [Page 16]
  990. DRAFT             Point-to-Point Protocol Requirements      October 1993
  991.  
  992.  
  993.    DDN X.25 and Commercial X.25 encapsulations are also supported.
  994.    Multiple protocols are supported by making protocol dependent CALL
  995.    REQUEST's.
  996.  
  997.  
  998. 4.3.2.  MIT PC/IP framing protocol
  999.  
  1000.    The MIT PC/IP framing protocol [13] provides a mechanism for the
  1001.    transmission of IP datagrams over asynchronous links.  The low-level
  1002.    protocol (LLP) sublayer provides encapsulation while the local net
  1003.    protocol provides multiplexing of IP datagrams and IP address request
  1004.    packets.  The protocol only allows host-to-gateway connections.
  1005.    Host-to-gateway flow control is provided by requiring the host to
  1006.    transmit request packets to the gateway until an acknowledgment is
  1007.    received.  Rudimentary IP address negotiation requires the host to
  1008.    ascertain its IP address from the gateway.
  1009.  
  1010.    The protocol does not implement error detection, connection status
  1011.    determination, fault detection or option negotiation.  Only
  1012.    asynchronous links are supported.
  1013.  
  1014.  
  1015. 4.3.3.  Proteon p4200 point-to-point protocol
  1016.  
  1017.    The Proteon p4200 multi-protocol router supports transmission of
  1018.    packets over bit-oriented synchronous links with a wide range of
  1019.    speeds (zero to 2 Mb/sec).  The p4200 point-to-point protocol
  1020.    encapsulates packets inside HDLC frames but does not use the HDLC
  1021.    address or control fields; these two octets are instead used for a
  1022.    16-bit type field.  The p4200 does use the HDLC frame check sequence
  1023.    trailer.  Protocol type numbers are ad hoc and do not correspond to
  1024.    any existing standard.  A simple liveness protocol detects dead
  1025.    connections.
  1026.  
  1027.    Although the Proteon protocol does meet many of our requirements, it
  1028.    does not meet our requirements for option negotiation.
  1029.  
  1030.  
  1031. 4.3.4.  Ungermann Bass point-to-point protocol
  1032.  
  1033.    The Ungermann Bass router supports synchronous links using simple
  1034.    HDLC framing.  Neither the HDLC address or control field are used, IP
  1035.    datagrams are placed immediately after the HDLC flag.
  1036.  
  1037.    The U-B protocol does not meet any of our requirements for fault
  1038.    detection or option negotiation.  No mechanism for future
  1039.    extensibility is currently defined.
  1040.  
  1041.  
  1042.  
  1043.  
  1044. Perkins                  expires in six months                 [Page 17]
  1045. DRAFT             Point-to-Point Protocol Requirements      October 1993
  1046.  
  1047.  
  1048. 4.3.5.  Wellfleet point-to-point protocol
  1049.  
  1050.    The Wellfleet router supports synchronous links using simple HDLC
  1051.    framing.  The HDLC framing procedure uses the HDLC address and places
  1052.    the Unnumbered Information (UI) command in all frames.  A simple
  1053.    header following the UI command provides a two octet type field using
  1054.    the same values as Ethernet.
  1055.  
  1056.    The Wellfleet protocol does not meet any of our requirements for
  1057.    fault detection or option negotiation.  No mechanism for future
  1058.    extensibility is currently defined, although one could be added.
  1059.  
  1060.  
  1061. 4.3.6.  XNS Synchronous Point-to-Point Protocol
  1062.  
  1063.    The Xerox Network Systems Synchronous Point-to-Point protocol (XNS
  1064.    PPP) [14] was designed to address most of the same issues that an
  1065.    ISPPP must address.  In particular, it addresses the issues of
  1066.    simplicity, transparency, efficiency, packet framing, protocol
  1067.    multiplexing, error detection, standard MTUs, symmetry, switched and
  1068.    non-switched media, connection status, network address negotiation
  1069.    and future extensibility.  However, the XNS SPPP does not meet our
  1070.    requirements for multiple data link layer protocols, fault detection
  1071.    and data compression negotiation.  Although protocol multiplexing is
  1072.    provided, the packet type field has only 8 bits which is too few.
  1073.  
  1074.  
  1075.  
  1076.  
  1077.  
  1078.  
  1079.  
  1080.  
  1081.  
  1082.  
  1083.  
  1084.  
  1085.  
  1086.  
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099. Perkins                  expires in six months                 [Page 18]
  1100. DRAFT             Point-to-Point Protocol Requirements      October 1993
  1101.  
  1102.  
  1103. References
  1104.  
  1105.    [1]   Postel, J., "Internet Protocol", RFC-791, USC/Information
  1106.          Sciences Institute, September 1981.
  1107.  
  1108.    [2]   Postel, J., "User Datagram Protocol", RFC-768, USC/Information
  1109.          Sciences Institute, August 1980.
  1110.  
  1111.    [3]   Electronic Industries Association, EIA Standard RS-232-C,
  1112.          "Interface Between Data Terminal Equipment and Data
  1113.          Communications Equipment Employing Serial Binary Data
  1114.          Interchange", August 1969.
  1115.  
  1116.    [4]   Mills, D. L., "DCN Local-Network Protocols", RFC-891, December
  1117.          1983.
  1118.  
  1119.    [5]   Farber, David J., Delp, Gary S., and Conte, Thomas M., "A
  1120.          Thinwire Protocol for Connecting Personal Computers to the
  1121.          Internet", RFC-914, University of Delaware, September 1984.
  1122.  
  1123.    [6]   Finn, G., "Reliable Asynchronous Transfer Protocol (RATP)",
  1124.          RFC-916, USC/Information Sciences Institute, October 1984.
  1125.  
  1126.    [7]   Robinson, J., "Reliable Link Layer Protocols", RFC-935, BBN,
  1127.          January 1985.
  1128.  
  1129.    [8]   Braden, R., and J. Postel, "Requirements for Internet
  1130.          Gateways", RFC-1009, USC/Information Sciences Institute, June
  1131.          1987.
  1132.  
  1133.    [9]   Romkey, J., "A Nonstandard for the Transmission of IP Datagrams
  1134.          Over Serial Lines: SLIP", RFC-1055, June 1988.  RFC-1009,
  1135.          USC/Information Sciences Institute, June 1987.
  1136.  
  1137.    [10]  ISO International Standard (IS) 3309, "Data Communications -
  1138.          High-level Data Link Control Procedures - Frame Structure",
  1139.          1979.
  1140.  
  1141.    [11]  CCITT Recommendation X.25, "Interface Between Data Terminal
  1142.          Equipment (DTE) and Data Circuit Terminating Equipment (DCE)
  1143.          for Terminals Operating in the Packet Mode on Public Data
  1144.          Networks", Vol. VIII, Fascicle VIII.2, Rec. X.25.
  1145.  
  1146.    [12]  CCITT Recommendation Q.921 "ISDN User-Network Interface Data
  1147.          Link Layer Specification".
  1148.  
  1149.    [13]  Romkey, J.L., "PC/IP Programmer's Manual", Massachussetts
  1150.          Institute of Technology Laboratory for Computer Science,
  1151.  
  1152.  
  1153.  
  1154. Perkins                  expires in six months                 [Page 19]
  1155. DRAFT             Point-to-Point Protocol Requirements      October 1993
  1156.  
  1157.  
  1158.          January 1986.
  1159.  
  1160.    [14]  Xerox Corporation, "Synchronous Point-to-Point Protocol", Xerox
  1161.          System Integration Standard, Stamford, Connecticut, XSIS
  1162.          158412, December 1984.
  1163.  
  1164.    [15]  "Digital Data Communications Message Protocol", Digital
  1165.          Equipment Corporation.
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179.  
  1180.  
  1181.  
  1182.  
  1183.  
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.  
  1193.  
  1194.  
  1195.  
  1196.  
  1197.  
  1198.  
  1199.  
  1200.  
  1201.  
  1202.  
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209. Perkins                  expires in six months                 [Page 20]
  1210. DRAFT             Point-to-Point Protocol Requirements      October 1993
  1211.  
  1212.  
  1213. Chair's Address
  1214.  
  1215.    The working group can be contacted via the current chair:
  1216.  
  1217.       Fred Baker
  1218.       Advanced Computer Communications
  1219.       315 Bollay Drive
  1220.       Santa Barbara, California  93117
  1221.  
  1222.       EMail: fbaker@acc.com
  1223.  
  1224.  
  1225. Author's Address
  1226.  
  1227.    Questions about this memo can also be directed to:
  1228.  
  1229.       Drew Perkins
  1230.       4015 Holiday Park Drive
  1231.       Murrysville, PA  15668
  1232.  
  1233.       EMail: perkins+@cmu.edu
  1234.  
  1235.  
  1236. Editor's Address
  1237.  
  1238.    Typographic revision and historical notes by:
  1239.  
  1240.       William Allen Simpson
  1241.       1384 Fontaine
  1242.       Madison Heights, Michigan  48071
  1243.  
  1244.       EMail: Bill.Simpson@um.cc.umich.edu
  1245.  
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264. Perkins                  expires in six months                 [Page 21]
  1265. DRAFT             Point-to-Point Protocol Requirements      October 1993
  1266.  
  1267.  
  1268.                            Table of Contents
  1269.  
  1270.  
  1271.      1.     Introduction ..........................................    1
  1272.         1.1       Definitions of Terms ............................    2
  1273.  
  1274.      2.     Required Features .....................................    4
  1275.         2.1       Simplicity ......................................    4
  1276.         2.2       Transparency ....................................    5
  1277.         2.3       Packet Framing ..................................    5
  1278.         2.4       Bandwidth Efficiency ............................    5
  1279.         2.5       Protocol Processing Efficiency ..................    5
  1280.         2.6       Protocol Multiplexing ...........................    6
  1281.         2.7       Multiple Physical and Data Link Layer Protocols .    6
  1282.         2.8       Error Detection .................................    6
  1283.         2.9       Standardized Maximum Packet Length (MTU) ........    7
  1284.         2.10      Switched and Non-Switched Media .................    7
  1285.         2.11      Symmetry ........................................    7
  1286.         2.12      Connection Liveness .............................    8
  1287.         2.13      Loopback Detection ..............................    8
  1288.         2.14      Misconfiguration Detection ......................    9
  1289.         2.15      Network Layer Address Negotiation ...............    9
  1290.         2.16      Data Compression Negotiation ....................    9
  1291.         2.17      Extensibility and Option Negotiation ............   10
  1292.  
  1293.      3.     Features Not Required .................................   11
  1294.         3.1       Error Correction ................................   11
  1295.         3.2       Flow Control ....................................   11
  1296.         3.3       Sequencing ......................................   11
  1297.         3.4       Backward Compatibility ..........................   11
  1298.         3.5       Multi-Point Links ...............................   12
  1299.         3.6       Half-Duplex or Simplex Links ....................   12
  1300.         3.7       7-bit Asynchronous RS-232 Links .................   12
  1301.  
  1302.      4.     Prior Work On PPP Protocols ...........................   13
  1303.         4.1       Internet Protocols ..............................   13
  1304.            4.1.1  RFC 891 - DCN Local-Network Protocols, Appendix A   13
  1305.            4.1.2  RFC 914 - Thinwire Protocols ....................   13
  1306.            4.1.3  RFC 916 - Reliable Asynchronous Transfer Protocol   14
  1307.            4.1.4  RFC 935 - Reliable Link Layer Protocols .........   14
  1308.            4.1.5  RFC 1009 - Requirements for Internet Gateways ...   14
  1309.            4.1.6  RFC 1055 - Serial Line IP .......................   14
  1310.         4.2       International Protocols .........................   15
  1311.            4.2.1  ISO 3309 - HDLC Frame Structure .................   15
  1312.            4.2.2  ISO 6256 - HDLC Balanced Class of Procedures
  1313.  
  1314.  
  1315.  
  1316. Perkins                  expires in six months                [Page iii]
  1317. DRAFT             Point-to-Point Protocol Requirements      October 1993
  1318.  
  1319.  
  1320.            4.2.3  CCITT X.25 and X.25 LAPB ........................   15
  1321.            4.2.4  CCITT I.441 LAPD ................................   16
  1322.         4.3       Other Protocols .................................   16
  1323.            4.3.1  Cisco Systems point-to-point protocols ..........   16
  1324.            4.3.2  MIT PC/IP framing protocol ......................   17
  1325.            4.3.3  Proteon p4200 point-to-point protocol ...........   17
  1326.            4.3.4  Ungermann Bass point-to-point protocol ..........   17
  1327.            4.3.5  Wellfleet point-to-point protocol ...............   18
  1328.            4.3.6  XNS Synchronous Point-to-Point Protocol .........   18
  1329.  
  1330.      REFERENCES ...................................................   19
  1331.  
  1332.      CHAIR'S ADDRESS ..............................................   21
  1333.  
  1334.      AUTHOR'S ADDRESS .............................................   21
  1335.  
  1336.      EDITOR'S ADDRESS .............................................   21
  1337.  
  1338.